In order to facilitate the activities in the test process, the test manager determines which test roles are required and how they are to be filled (see Test Professionals and Roles). These will include, for example:

• Test management or test coordination
• Test team leading
• Tester
• Management (test process, test products, defects)
• Intermediary
• Support (domain knowledge, system knowledge, test environment, test tools or test method).

Make as much use here as possible of the roles set out at coordinating level.

The tasks and responsibilities are set out here per required role.

The correlations between the roles mentioned and the relationships with the other stakeholders within the system development process have to be determined and established. The organisation of the test level naturally forms part of a bigger whole. If the whole is a project, the test manager should also establish a relationship with the test or quality department, if any. For the organisation of a test level, the possibilities can largely be defined as follows:

1. Testing as an independent activity or integrated with other activities
2. Testing placed within a project or in a line organisation

These choices are dependent on the test level, project and organisation. Sometimes, but by no means always, the test manager can exert influence on this. For a broader explanation of testing in a line organisation, refer to Permanent Test Organisation

 Figure 1: Organisational divisions with examples

It is impossible to determine one preferred organisation for testing. In general, the structure of the test organisation should resemble that of the associated process of system development or package implementation. In many cases, this means the project organisation. If there is to be frequent (re)testing in combination with scarce (test) knowledge, the permanent test organisation discussed in Permanent Test Organisation becomes a candidate.

The people involved in the test levels should have various types of knowledge, particularly in the areas of testing, domain knowledge and system.

• For testing, this may include: (the advantages of) the test approach, strategy determination, test techniques and tools to be applied
• For domain knowledge, bear in mind, for example, the organisation and its business processes
• System knowledge may consist of knowledge of the development or implementation process, design techniques, technical architecture, database or programming tools, etc.

From within the test process, communication takes place with various parties. Examples of the parties with whom the test manager communicates are:

• Client
• Test manager of the overall test process
• Project management (including Change Control Board)
• Accepters (user organisation, system administration, functional management)
• Steering group
• Project leaders (design, construction and/or implementation)
• Developers
• Testing line organisation
• Quality management, QA
• Accountancy, EDP auditing.

It should be agreed with each party whether consultation and/or reporting is to take place, and what the aims and frequency of these should be.

Consultation forms

As regards consultation forms, it should be agreed who will be present and what, if any, the standard agenda will be. Examples of consultation forms for use by the test manager are:

• Weekly consultation with all the other test managers, directed by the test manager of the overall test process
• Weekly project consultation
• Weekly Change Control Board consultation
• Defects consultation (1 x per week as standard; 3 x per week during test execution)
• Weekly test team meeting
• Daily stand-up meeting.

Below is an example of a fixed agenda for a test team meeting:

Reports

According to the BDTM view, reporting takes place on the four aspects of Result, Risks, Time and Costs.

• Result
  
  
  • The outcome of the tests executed at the level of characteristic/object part
  • The result in terms of obtained/not-obtained test goals (business processes, user requirements, etc.)
  • Any trend analyses
    
    
• Risk
  
  
  • Detection of parts that are being tested more superficially (or not at all) than the risk estimate indicates, thus presenting a higher risk
  • Detected (test) project risks
    
    
• Time + Costs
  
  
  • Progress of testing (in activities, products, hours spent and, optionally, money, dates)
  • Indication of when the testing will be completed.

Reporting on risks and results takes place at the level of test goals, as agreed with the client and other stakeholders. The risk tables of the product risk analysis are maintained with this aim. It is up to the test manager to translate test results on characteristics/object parts effectively, and on the basis of the tables, to this level.

Reporting can take place in various ways, to various target groups and at various times. The most important forms of reporting are:

• Progress and quality reports - Information and advice on progress (and, optionally, quality) of the test process and on quality/risks of the test object, based on the four BDTM aspects. Frequency: periodically, preferably weekly.
• Risk report - With certain (project) risks, the test manager can, either upon request or at his own initiative, report on risk, the consequences for the test process and possible measures for dealing with the risk. In the Prince2 project management method these are known as exception reports’. Frequency: ad-hoc.
• Release advice - Information and advice on quality/risks of the test object + formally established release advice. Frequency: towards the end of the test execution, before the decision has to be taken on release.
• Final report - Evaluation of the test process and test object, looking back from the original plan. Frequency: once, at the end of the test process.

The test manager will determine, for each of these forms of report, to whom they should be sent, whether for approval or for information, with what content and degree of detail and with what frequency. In the activity, “Understanding the assignment” the test manager has already looked at which parties should, or wish to, receive reports. In consultation with the client, that is now determined in more detail. As an aid in overseeing who should receive which report, a matrix can be set up of report forms and target groups. The report forms and content are discussed in detail in Report (AST).